Legacy IBM x86-based processor architectures relied primarily on a basic input/output system (BIOS) to initiate platform hardware and initiate loading of the operating system (OS) for the system. Instigated by certain limitations in the BIOS architecture, original equipment manufacturers (OEMs) developed a new specification, the Extensible Firmware Interface (EFI), and later the Unified EFI (UEFI), for managing the pre-boot environment after the platform is powered on and before the OS is loaded. The UEFI specification (which incorporates the earlier EFI specification) describes a platform initialization (PI) phase, or pre-boot phase, and the interface between the operating system and the system firmware. To this end, the UEFI specification provides guidelines for drivers that provide levels of abstraction from the hardware devices of the system. These abstractions provide other UEFI drivers and applications an interface (referred to as “protocols” in UEFI) to the hardware devices managed by the driver producing the abstraction. As an example, an embedded microcontroller (EC) input/output (IO) driver in accordance with the UEFI specification will be responsible for all IO communication with the EC, which might involve, for example, a set of rules that ensure the host system and the EC remain synchronized. An EC IO transaction thus could begin with a handshake between the host and EC to initiate a transaction, followed by a period of time where the EC is internally executing various commands. The transaction might complete some time later when the EC initiates a handshake signaling completion of the transaction. In this case, it is the responsibility of the EC IO driver to ensure that each transaction with the EC is atomic. In other words, the EC IO driver must make sure every host-to-EC transaction is completed before the next transaction begins.
UEFI breaks platform initialization (PI) into several phases, with the bulk of the platform initialization state spent in the Driver Execution Environment (DXE). As such, the drivers that produce the IO protocols for the hardware devices of the system typically are utilized in the DXE. Further, on many systems, a System Management Mode (SMM) will be initialized and enabled by a DXE application during the DXE. The SMM environment can be designed to mimic the DXE environment. Just like DXE drivers, SMM drivers can be written to produce protocols that provide hardware abstractions. In fact, the same protocol definitions used in DXE can be applied to SMM. Thus, it is possible that, once SMM is initialized, two drivers (one in DXE, one in SMM) that produce the IO protocol for a particular hardware device can exist in the system at the same time. With the SMM initiated, the system may enter SMM at any time and temporarily suspend DXE. If a DXE driver managing a hardware interface is in the middle of an IO transaction at the time the system enters SMM, the transaction is suspended by a processor of the system, whereby the system typically saves the configuration index and data registers of the DXE drivers on entry to SMM and restores them on exit from SMM. Care must be taken to ensure that nothing is executed in SMM that might compromise the integrity of IO transactions initiated in DXE. In the case of the EC IO driver example described above, simply saving and restoring the configuration index and register data may not be sufficient because IO transactions managed by the EC IO driver may involve the EC executing internal instructions for long periods before returning to the host and signaling completion of the transaction. If an SMM event occurs in the middle of a DXE-initiated EC IO transaction, that transaction has a high probability of failure if an SMM driver initiates an EC IO transaction. Accordingly, an improved technique for managing IO transactions in the presence of multiple drivers for a particular hardware device would be advantageous.
The use of the same reference symbols in different drawings indicates similar or identical items.